1. Field of the Invention
This invention relates to data processing systems and to improvements in device driver design methodology. More particularly, the invention relates to device drivers supporting a wide variety of operating systems, network protocols and adapter hardware.
2. Description of the Prior Art
The development of various types of Local Area Networks (LAN) and Wide Area Networks (WAN) adapters for data processing systems presents a challenge from both the hardware and software perspective. Designing and building the adapter card itself is a sizable task, and is one that is usually the most familiar. The requisite support software, on the other hand, is less understood and can easily be underestimated (or overlooked) when budgeting time or resources for a project. This is especially true in the area of device drivers, which are critical elements to the success of an overall adapter project, and whose development is the subject of this invention.
Contributing to the problem of adapter device driver development is the fact that there are an abundance of interface categories, such as system platform, bus types, adapter hardware, network protocols, etc., each of which affects the design of a device driver. This is not a new problem, however, and attempts have been made to reduce complexity by defining types of common interfaces at the network-data-link layer. Both Open-Data Link Interface (ODI) from Novell Corporation and the Network Driver Interface Specification (NDIS) from 3Com and Microsoft Corporations, define well-known (although different), defacto standardized programming interfaces which serve to isolate an adapter Media Access Control (MAC) driver from the network protocol software that runs in the layer(s) above it. The advantage of this is apparent when a new hardware adapter product is introduced to the marketplace which, when supplied with the proper ODI and/or NDIS compliant device drivers, will usually work in those existing environments respectively.
Attempting to standardize the network interface is a step in the right direction, but is not enough from an overall adapter development perspective. Often, support for both the ODI and NDIS network interface is required along with others. To develop a sufficient set of device drivers for the product, one needs to also consider several other interface categories, such as those mentioned previously. Taking into account that each of these categories can have multiple types, the number of possible combinations grows exponentially, making it difficult to manage the development of a full set of device drivers. Also, since each device driver serves a unique purpose and is often developed by a different person(s) with a particular area of expertise, code duplication can be excessive when viewed across all of the drivers, and similar functions run the risk of being implemented differently.
In simplest terms, the problem addressed by the invention is the current inability to mass produce a full set of required device drivers in time for initial delivery of an adapter product. Due to the rapidity of product introduction, the incessant technological changes that accompany them, and the industry-wide trend toward overall work force reduction, it is no longer feasible to custom-build each individual device driver with only a minimal amount of design and code sharing if any. The ultimate goal is to have a process that can best be described as "push button" device driver development, wherein the developer selects the key components of the device driver and it is automatically built.
A solution to the stated problem is to re-architect device drivers into three main software components: System, Network and Adapter. The three component device driver model offers the necessary and sufficient degree of interaction and dependence to support operating systems, network protocols and adapter hardware interfaces, respectively, while simultaneously minimizing redundant designs and implementation of LAN/WAN device drivers. When fully implemented in a three component device driver, a developer can select one of each component to build the desired device driver, producing in a single driver, an executable file as a result.
As new adapter products emerge, only a new Adapter component needs to be developed at a fraction of the current development time, and it can be combined in various combinations of System and Network components to create a full set of unique device driver executable files, which can be used to support the product in different operating environments. Similarly, support for new operating systems and/or network protocol interfaces can be added by creating new System and/or Network component implementations resulting in support for a full range of adapter products through their existing Adapter components. Thus, a wide range of device driver executable files can be easily created simply by choosing different combinations of a System, Network, and an Adapter component from the available set of component implementations.
From an architectural perspective, a device driver model consisting of three primary components is deemed to be optimal. Fewer components typically result in increased code duplication among different device drivers as well as an excessive reliance upon multiple levels of conditionally-included code, both of which lead to problems with maintaining and supporting the device drivers. A model based on more than three primary components becomes needlessly complex and increases the driver inter-component communications, resulting in less desirable operating performance characteristics. Though some operating environments tend to blur the distinction between the System and Network components from an implementation perspective, these remain distinct entities architecturally and have clearly defined responsibilities, which is the premise of this invention.
The prior art related to the present invention is as follows:
U.S. Pat. No. 4,649,479 to H. Advani et al., issued Mar. 10, 1987, describes a device driver and adapter binding technique in which an operating system having device drivers is run as a virtual machine on a virtual resource manager having device drivers of real and virtual devices. A device dependent information file corresponding to a device is created. This file contains adapter dependent information including a hardware port address for the physical device. A "token" is in the operating system device driver at the time it is initiated. When the operating system device driver is "open" to drive the device, it uses the "token" to communicate with the virtual resource manager device driver thereby accomplishing the driver-to-driver binding. This causes the virtual resource manager device driver to use the adapter-dependent information in a special file corresponding to the "token" and placed in the process stack.
U.S. Pat. No. 5,265,252 to F. Rawson, III, issued Nov. 23, 1993, discloses a generic device driver core having a generic operating system interface generic to a plurality of different operating systems including an install operating system. The core is portable between different operating systems and has a plurality of specific device drivers connected to I/O devices for controlling operation of the I/O devices. A conversion means functionally layered between the specific device driver interface of the installed operating system and the generic operating system interface of the device driver converts I/O requests and responses between the specific device driver and operating system and the generic operating system interface of the device driver core to thereby adapt the generic device driver core to operate specifically with the installed operating system.
U.S. Pat. No. 5,379,296 to R. A. Johnson et al., issued Jan. 3, 1995, discloses an interface which enables a "LAN" connected work station to concurrently communicate with a plurality of computer platforms having respective network architecture over the same physical connection. The interface receives data from a LAN connection, examines the data and identifies the format being used. Based on the identified format, the interface determines the appropriate destination for the data and sends the data to that destination.
U.S. Pat. No. 5,586,268 to K. C. Chen et al., issued Dec. 17, 1996, and filed Mar. 3, 1995, discloses a device driver to control multiple peripheral devices in a computer system. First and second interface buses permit interconnection of peripheral adapters with a central processor. The interface buses each correspond to different classes of peripheral adapters. The device driver includes an initialization routine for scanning the interface buses to identify predetermined functionally-related peripheral adapters. A communication path is provided between the operating system and each of the peripheral adapters of a form appropriate for the particular interface bus connected to each adapter. A control path is also provided between each of the peripheral adapters and the operating system of a form appropriate for the particular interface bus connected to each adapter. The core device driver provides for the common control and management of the communication and control paths between the operating system and each of the peripheral adapters.
None of the prior art discloses a device driver architecture which has three main components and which enables a developer to select components to support a wide variety of operating systems and platforms; network protocols and adapter hardware.